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from its associated PDP address and a traffic flow template (TFT) for filtering the transferred 



data. 
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Each PDP context can be selectively and independently activated, modified, and 
deactivated. The activation state of a PDP context indicates whether data transfer is 
5 enabled for a corresponding PDP address and TFT. If all PDP contexts associated with the 
same PDP address are inactive or deactivated, all data transfer for that PDP address is 
disabled. All PDP contexts of a subscriber are associated with the same Mobility 
Management (MM) context for the International Mobile Subscriber Identity (IMSI) of that 
subscriber. Setting up a PDP context means setting up a communication channel. 
10 FIG. 1 is a process flow diagram that illustrates an example of the PDP context 

activation procedure. In step 100, the MT sends an Activate PDP Context Request to the 
SGSN. The Activate PDP Context Request message sent in step 100 includes a number of 
parameters. The parameters include a PDP address and an Access Point Name (APN). 
The PDP address is used to indicate whether a static PDP or dynamic PDP address is 
required. The APN is a logical name referring to the Gateway GPRS Support Node (GGSN) 
to be used. 

In step 102, the SGSN sends a Radio Access Bearer (RAB) setup message to the 
UMTS Terrestrial Radio Access Network (UTRAN) or the GERAN or other corresponding 
radio access networks . In step 104, the SGSN sends a Create PDP Context Request 
20 message to the affected GGSN. The GGSN decides whether to accept or reject the 

request. If it accepts the request, it modifies its PDP context table and returns a Create PDP 
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Context Response message in step 106. The SGSN then sends an Activate PDP Context 
Accept message to the Mobile Temiinal in step 108. 

In spite of the numerous details provided in the aforementioned protocol, many 
features associated with mobile netv^orks have not been dealt with. Specifically, charging 
5 information can be created by the SGSN, the GGSN and by the IP telephony network 

elements, e. g. the CSCF, and at present there is no solution in place to provide any means 
to associate the charging information created by the SGSN. the GGSN and the charging 
information created by the CSCF. This is needed in order to implement network functionality 
such as hot billing or merely to allow a network operator to implement joint billing for GPRS 
10 services and IP telephony services. 
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c;i IMMARY OF THE INVENTION 
According to a first illustrative embodiment of the invention, when an Activate PDP 
Context Request message is fonvarded to a Service GPRS Support Node (SGSN) by an 
1 5 MT, the SGSN creates a Create PDP Context Request message and fonwards it to a 

Gateway GPRS Support Node (GGSN). In response to the Create PDP Context Request 
forwarded by the SGSN, the GGSN creates a Create PDP Context Response message. 
When a PDP context is created by the GGSN. the GGSN associates a Charging 
Identification parameter with the PDP context. Then, the Create PDP Context Response 
20 including the Charging Identification parameter is forwarded to the SGSN. In response to 
the PDP Context Response fonwarded by the GGSN to the SGSN, the SGSN foPA/ards an 
Activate PDP Context Accept message to the MT. According to the first embodiment of the 



3 



# 



ifl 10 



15 



20 



Docket No. 017.38448X00 (NC17179) 

invention, both the Charging Identification parameter and possibly the GGSN address are 
provided to the MT in the Activate PDP Context Accept message. As described herein, the 
mobile station (MS) includes two parts: the terminal equipment (TE) and the mobile terminal 
(MT). The MS may also be referred to as user equipment (UE). The TE can, e.g., be a 
laptop which is then connected to the MT. The MT can be a mobile phone. 

Sending the GGSN address is not mandatory. Another alternative is that the CSCF 
adds the IP address of the MS to the charging records (CDRs) that it creates for a call. The 
SGSN and the GGSN already add the PDP address of the PDP context to the CDRs. By 
checking that the PDP address is the same as the IP address, it can be ensured that the 
PDP context has been used for the call in question. Since this requires that the charging 
identifications are the same, the CSCF adds the Charging Identification to the CDRs that it 
creates for the call in question. 

According to a second illustrative embodiment of the invention, the Charging 
Identification can be sent from the SGSN or the GGSN to the Call State Control Function 
(CSCF). When an Activate PDP Context Request message is forwarded to the SGSN. the 
SGSN creates a Create PDP Context Request message. The SGSN sends the Create 
PDP Context Request to the GGSN. In response to the Create PDP Context Request 
received from the SGSN. the GGSN creates a Create PDP Context Response. The GGSN 
associates the Charging Identification parameter with the PDP context. The Create PDP 
Context Response including the Charging Identification parameter is then forwarded to the 
SGSN. 
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The Charging Identification parameter can be sent from either of the SGSN or the 
GGSN directly to the CSCF; and, such sending of the Charging Identification parameter can 
be performed either autonomously, e.g., at PDP context activation, or based on a request 
from the CSCF. 

5 In a specific embodiment, the CSCF sends the charging identification towards an 

endpoint of a communication, and sends security information together with said charging 
identification toward the endpoint. The CSCF is able to send an address of a GGSN 
together with the charging identification to the endpoint. If the GGSN address is not sent 
with the charging identification, the CSCF adds the IP address of the mobile station (UE) to 
10 the CDRs. 

The principles of the invention are applicable to other types of communication 
channels in addition to PDP contexts. 

Other aspects and advantages of the invention will become apparent from the 
following detailed description and accompanying drawings, illustrating by way of example 

£ 1 5 the features of the invention. 

3 

RRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing and a better understanding of the present invention will become 
apparent from the following detailed description of example embodiments and the claims 
20 when read in connection with the accompanying drawings, all forming a part of the 
disclosure of this invention. While the foregoing and following written and illustrated 
disclosure focuses on disclosing example embodiments of the invention, it should be clearly 
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understood that lt,e same is by way of Illustration and example only and the Invention is not 
limited thereto. The spirit and scope of the present invention are limited only by the terms of 

the appended claims. 

Figure 1 is a generalized process flow diagram iliustratir^g the PDP context activation 

5 procedure. 

Figure 2 is a generalized block diagram of the architecture of a packet switched 
wireless communication network in which the example embodiments of the invention can be 

practiced. 

Figure 3 Is a generalized process flow diagram Illustrating sending a charging 
10 identification In accordance with a first embodiment of the present invention. 

Figure 4 is a generalized process flow diagram Illustrating sending a charging 
identification in accordance with an arrangement of a second embodiment of the present 

invention. 

Figure 5 is a generalized process flow diagram illustrating sending a charging 
, 5 identification in accordance with another arrangement of the second embodiment of the 
invenfion. 

r>FTAll Fn DESCR IPTinN OF THE INVENT ION 
Before beginning a detailed description of the subject Invention, mention of the 
20 following is in order, when appropriate, like reference numerals and characters may be used 
to designate identical, corresponding, or simitar components In differing drawing figures. 



Docket No. 017.38448X00 (NC17179) 

Furthermore, in the detailed description to follow, example sizes/models/values/ranges may 
be given, although the present invention is not limited thereto. 

An example of a network architecture supporting these specifications is the wireless 
communications network shown in the block diagram of FIG. 2. The various elements of the 
network and their functions are described in the General Packet Radio Service (GPRS) 
Service Description, Stage 2, 3GPP TS 23.060. published by the 3rd Generation 
Partnership Program f www.3aPD.orq) . The elements and their functions may be described 
in earlier or later versions of the 3GPP TS 23.060 specifications or maybe those of any other 
known packet switched wireless communications network. The description of network 
elements and their functions are merely a non-limiting example of packet switched wireless 

communication networks. 

Several elements of the example network illustrated in FIG. 2 are particularly 
relevant to this invention. The Mobile Terminal (MT), commonly referred to as a cell phone 
or a mobile phone, is only one possible part of User Equipment (UE). Typically. Terminal 
Equipment (TE). used together with a Mobile Terminal (MT), constitutes User Equipment 
(UE), which is also referred to as a Mobile Station (MS). Any UE may be utilized in 
conjunction with this invention so that it operates or can be programmed to operate in the 
manner described below. The UMTS Terrestrial Radio Access Network (UTRAN) and the 
Base Station System (BSS) in GPRS manage and control the radio access between the 
core network and a number of MTs. There are also other possible radio access networks 
like GERAN. 
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The CSCF is a network element in an IP telephony network. The IP telephony 
network is sometimes referred to as "the application layer". The structure and function of the 
Call State Control Function (CSCF) can be divided into several logical components, which 
are currently internal to the CSCF. Every CSCF acting as a Serving CSCF has a Call 
Control Function (CCF) function. The CSCF includes an ICGW (Incoming call gateway). 
The ICGW acts as a first entry point. The ICGW performs routing of incoming calls. 
Incoming call service triggering (e.g. call screening /call forwarding unconditional) may need 
to reside for optimization purposes. The ICGW performs Query Address Handling (implies 
administrative dependency with other entities); and communicates with the Home 

Subscriber Server (HSS). 

The CCF (Call Control Function) performs call set-up/termination and state/event 
management; interacts with MRF in order to support multi-party and other services; reports 
call events for billing, auditing, intercept or other purposes; receives and process application 
level registration; performs query address handling (implies administrative dependency); 
and may provide service trigger mechanisms (service capabilities features) towards 
application & services network (VHE/OSA). The CCF may invoke location based services 
relevant to the serving network, and may check whether the requested outgoing 
communication is allowed given the current subscription. 

The CSCF includes a SPD (Serving Profile Database). The SPD interacts with HSS 
in the home domain to receive profile information for the ROO all-IP network user and may 
store them depending on the SLA with the home domain. The SPD notifies the home 
domain of initial user's access (which includes, e.g.. CSCF signalling transport address, user 
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ID, etc.) The SPD may cache access related information (e.g. terminal IP address(es) 

where the user may be reached, etc.) 

The CSCF performs AH (Address Handling) function. The AH function includes 

analysis, translation, modification, if required, address portability, and mapping of alias 

addresses. The AH function may do temporary address handling for inter-network routing. 
The Serving GPRS Support Node (SGSN) is the node that serves the MT. At PDP 

context activation, the SGSN establishes a PDP context used for routing purposes. The 
Gateway GPRS Support Node (GGSN) is the node accessed by the external packet data 
network due to evaluation of the PDP address. It contains routing information for attached 
GPRS/UMTS users. The routing information is used to tunnel Protocol Data Units (PDUs) to 
the SGSN. The SGSN and GGSN functionalities may reside in different physical nodes or 
may be combined in the same physical node, for example, the Internet GPRS Support Node 
(IGSN). 

The IP-based mobile network architecture includes an application level and a 
transport level. The transport level protocols and mechanisms are usually optimized for the 
specific type of access whereas the application level is normally generic, that is independent 
of the type of access. 

In IP-based mobile networks, the UE sets up a call by signaling to the peer entity and 
exchanging messages of a call control protocol over an IP connection provided by the 
transport levels. In setting up a call in the application level, the underlying transport level 
has to set up the transport bearers over the radio interface and in the transport network. For 
an IP-based mobile network, setting up of transport bearers means allocating radio 
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resources and network resources. The call control signaling is transparently exchanged over 
an IP connection provided by the transport level. 

Embodiment 1 

FIG. 3 illustrates a process of sending a charging identification in accordance with a 
first embodiment of the present invention. In UMTS all-IP networks, when GPRS/UMTS is 
adopted as access/transport network for multimedia and voice over IP services, charging will 
be performed independently at the GPRS/UMTS layer and at the application layer (e.g., the 
CSCF). 

In the GPRS and UMTS networks, PDP contexts are created by the GGSN upon 
request from the SGSN (with a Create PDP Context Request message) that, in turn, 
receives the request from the MT (an Activate PDP Context Request message). 

As illustrated in FIG. 3, the technique in accordance with the present invention 
begins at the application level at step 300 in which a trigger is fonvarded from the TE 
(Terminal Equipment) to the MT (Mobile Terminal). The trigger may be, e.g., a call set up 
indication including the requested logical channels and characteristics, sent from the TE to 
the MT to start PDP context activation. 

At step 302, an Activate PDP Context Request message is forwarded to the SGSN. 
In response thereto, in step 304. the SGSN creates a Create PDP Context Request 
message and fon/vards it to the GGSN. In response to the Create PDP Context Request 
forwarded by the SGSN. in step 306. the GGSN creates a Create PDP Context Response 
message. 
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In step 308, when a PDP context is created by the GGSN. the GGSN associates a 
Charging identification parameter with the PDP context in step 308. Then, in step 310. the 
Create PDP Context Response message including the Charging Identification parameter is 

forwarded to the SGSN. 

In turn, in response to the PDP Context Response forwarded by the GGSN to the 
SGSN. in step 312. the SGSN fonwards an Activate PDP Context Accept message to the 
MT. According to the first embodiment of the invention, both the Charging Identification 
parameter and the GGSN Address are provided to the MT in the Activate PDP Context 
Accept message. 

The above noted procedures in steps 300-312 are repeated as many times as 
needed depending on the PDP contexts needed. 

Upon the completion of the last procedure in step 312. the UE forwards a call set up 
message, including requested logical channels and characterisHcs, to the CSCF (Call State 
Control Function) in step 314. The MT will, in turn, provide the Charging Identificafion and 
the GGSN Address to the CSCF within the call set up message. The CSCF, in turn, 
forwards the call set up message, including requested logical channels and characteristics, 
to the remote end point in step 316. The remote end point then forwards a response 
message, including accepted logical channels and characteristics, back to the CSCF in step 
318. The CSCF then forwards the response message, including accepted logical channels 
and characteristics, to the UE in step 320. The response message may be. e.g.. the 
Connect message in H.323 or a SIP response message, but not necessarily limited to those. 
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The invention contemplates that the Charging Identification parameter can be made 
more secure by applying appropriate cryptographic algorithms to avoid a false Charging 
Identification being fonwarded by a malicious MT to the CSCF instead of the legitimate 
value, or a malicious MT re-using a value of the Charging Identification. 

From the foregoing, it will be appreciated that in the first embodiment of the 
invention, the Charging Identification parameter is sent from the SGSN to the UE and from 
the UE to the CSCF. 

Embodiment 2 

FIG. 4 illustrates a process of sending a charging identification in accordance with an 
arrangement of a second embodiment of the present invention. In UMTS all-IP networks, 
when GPRS/UMTS is adopted as the access/transport network for multimedia and voice 
over IP services, charging will be performed independently at the GPRS/UMTS layer and at 
the application layer (e.g., the CSCF). 

In the GPRS and UMTS networks, PDP contexts are created by the GGSN upon 
request from the SGSN (i.e., a Create PDP Context Request message) that, in turn, 
receives the request from the MT (i.e.. an Activate PDP Context Request). According to the 
second embodiment of the invention, the Charging Identification parameter is sent from the 
SGSN or the GGSN to the CSCF. Unlike the first embodiment, there is no need to send the 
Charging Identification parameter via the UE. 

As described previously, in the first embodiment of the invention, the MT intercepts 
data packets that are sent from the TE and adds the Charging Identification parameter to a 
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specific data packet ( the SIP message or the H.323 message for call set up). Interception 
of data packets may decrease the performance of the MT. 

In the second embodiment of the invention, the GPRS/UMTS and IPT network 
elements are able to co-ordinate charging information, e.g.. in order to combine charging 
information collected for a PDP context by the SGSN and the GGSN and for a call by the 
CSCF. Like the first embodiment, the GGSN allocates a Charging Id parameter at PDP 
context activation. And like the first embodiment, the GGSN sends the Charging Id 
parameter to the SGSN. But. unique to the second embodiment, the Charging Identification, 
possibly together with other information (e.g., IMSI, MSISDN. PDP address. UE port number 
from the TFT, Charging Characteristics etc.) can be sent from the SGSN or the GGSN to the 
CSCF. 

Sending the Charging Id parameter can be performed either autonomously or based 
on a request from the CSCF. The SGSN will send the Charging Identification, since the 
address of the CSCF has to be known if something will be sent to it. The SGSN has an 
interface with the HSS (HLR+UMS), which contains the address of the serving CSCF. 

There also can be an interface between the GGSN and the CSCF. This new 
interface could then be used to cany the Charging Id and possibly other charging related 
information. FIG. 4 illustrates an aspect of the second embodiment of the invention in which 
the SGSN sends the Charging-ld parameter to the CSCF. 

As illustrated in Figure 4, a process of sending a charging identification in 
accordance with the present invention begins at step 400 in which a trigger is fooA^arded 
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from the TE (Terminal Equipment) to the MT (Mobile Terminal). The trigger may be. e.g.. a 
call set up message including the requested logical channels and characteristics. 

At step 402. an Activate PDP Context Request message is fon/.arded to the SGSN. 
ir, response thereto, in step 404. the SGSN creates a Create PDP Context Request 

message. 

In step 406, the SGSN sends the Create PDP Context Request to the GGSN. In 
response to the Create PDP Context Request received from the SGSN, in step 408, the 
GGSN creates a Create PDP Context Response. In step 410, the GGSN associates the 
Charging Identification parameter with the PDP context. In step 412, both the Create PDP 
Context Response and the Charging Identfflcation are then returned to the SGSN in the 
Create PDP Context Response message. 

The Charging Id is included in the CDRs created by the GGSN and the SGSN. The 
CDRs are sent to the Charging Gateway Functionality (CGR) for further processing. From 
the Charging Gateway Functionality, the CDRs are sent to the Billing System. This is true 
for all the embodiments. In addition, it is important that the CSCF adds the Charging Id to 
the CDRs that it creates for the call in question. The CSCF sends CDRs either to the 
Charging Gateway Functionality (CGF) or to the Billing System. This way. when creating a 
bill for a subscriber, the PDP context(s) that were used for a specific call can be checked. 
The Charging Identification in all those CDRs is the same. 

If the Charging Characteristics change during an active PDP context, the SGSN 
includes the new Charging Characteristics of the PDP context in an Update PDP Context 
Request message, which the SGSN sends to the GGSN. 
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According to this arrangement of the second embodiment, the Charging Id 
parameter, possibly together with other information (e.g.. IMSI. MSISDN. PDP address. UE 
port number from the TFT. Charging Characteristics etc.). is sent from the SGSN directly to 
the CSCF in step 414. This is done either autonomously (in a first case) or based on a 
request from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the SGSN sends a 
message including the Charging Id and possibly other information (see above) to the CSCF. 
The message sent by the SGSN may be acknowledged by the CSCF. 

The SGSN must know the CSCF address. The CSCF address may be requested 
from the HSS or may be derived from the TFT which the UE specifies for the PDP context 
which is used for the communication with the CSCF. 

In the second case, at call set up. the CSCF requests information from the SGSN. 
The request is based, e.g.. on IMSI or MSISDN. The SGSN sends the Charging Id and 
possibly other information (see above) to the CSCF. 

The CSCF must know the SGSN address. The SGSN address may be requested 

from the HSS. 

The CSCF. in turn, fonA^ards the call set up message to the remote end point in step 
416. The remote end point then fonA^ards a response message back to the CSCF in step 
418. The CSCF then forwards the response message to the UE in step 420. 

FIG. 5 illustrates another arrangement of the second embodiment of the invention in 
which the GGSN sends the Charging Identification directly to the CSCF. Referring to FIG. 5. 
a process of sending a charging identification in accordance with the present invention 
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begins at step 500 in which a trigger is fonA^arded from the TE to the MT (Mobile Terminal). 
The trigger may be, e.g., a call set up message including the requested logical channels and 
characteristics. 

At step 502, an Activate PDP Context Request message is forwarded to the SGSN. 
In response thereto, in step 504, the SGSN creates a Create PDP Context Request 
message. In step 506, the SGSN sends the Create PDP Context Request to the GGSN. 

In response to the Create PDP Context Request received from the SGSN, in step 
508, the GGSN creates a Create PDP Context Response. In step 510, the GGSN 
associates the Charging Identification parameter with the PDP context. In step 512, the 
Create PDP Context Response message including the Charging Identification is then 
returned to the SGSN. 

According to this aspect of the second embodiment, the Charging Id parameter, 
possibly together with other information (e.g., IMSI, MSISDN, PDP address, UE port number 
from the TFT, Charging Characteristics etc.), is sent from the GGSN directly to the CSCF in 
step 514. Step 514 is performed either autonomously (in a first case) or based on a request 
from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the GGSN sends a 
message including the Charging Id and possibly other information (see above) to the CSCF. 
The message sent by the GGSN may be acknowledged by the CSCF. 

The GGSN needs to know the CSCF address. The CSCF address may be 
requested from the HSS or may be derived from the TFT which the UE specifies for the PDP 
context that is used for the communication with the CSCF. 
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In the second case, at call set up. the CSCF requests information from the GGSN. 
The request is based, e.g.. on IMS! or MSISDN. The GGSN sends the Charging Id 
parameter and possibly other information to the CSCF. 

The CSCF fonA/ards the call set up message to the remote end point in step 516. 
The remote end point then fonvards a response message back to the CSCF in step 518. 
The CSCF then fonA^ards the response message to the UE in step 520. 

The second embodiment allows the GPRS and IPT network elements to co-ordinate 
charging information, e.g., in order to combine charging information collected for a PDF 
context by the SGSN and the GGSN and for a call by the CSCF. Sending the Charging 
Identification from the SGSN or the GGSN to the CSCF requires an interface between the 
application level network and the transport level network. 

It is to be noted that in the description of the invention above, numerous details 
known to those skilled in the art have been omitted for the sake of brevity. Such details are 
readily available in numerous publications including the previously cited protocol. 

Although the present invention has been described with reference to a number of 
illustrative embodiments, it should be understood that numerous other modifications and 
embodiments can be devised by those skilled the art which will fall within the spirit and 
scope of the principles of this invention. More particularly, reasonable variations and 
modifications are possible in the component parts and/or arrangements of the subject 
combination arrangement within the scope of the foregoing disclosure, the drawings, and 
the appended claims without departing from the spirit of the invention. In addition to 



17 



Docket No. 017.38448X00 (NC17179) 

variations and modifications in the component parts and/or arrangements, alternative uses 
m\\ also be apparent to those skilled the art. 
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